The invention pertains to an apparatus and method for communicating between a controller and a message processing device over a Universal Serial Bus (USB).
Peripheral devices are linked to a controller (e.g., a personal computer) using various connections and communication protocols. Examples include a printer linked via a parallel port, a personal computer mouse linked via a serial port, a modem linked via a card slot (e.g., PCI, PCMCIA), etc. Likewise, many test and measurement devices link to a controller using a General Purpose Interface Bus (GPIB).
According to industry standards (e.g., IEEE 488.1, IEEE 488.2, IEC 60625.1, etc.), the GPIB is a sixteen line, bit parallel, byte serial bus. The GPIB has eight data input/output (DIO) lines, three handshake lines for reliable data transfer, and five lines for interface management (i.e., REN, ATN, IFC, SRQ, and EOI). The attention (ATN) line distinguishes between device data (e.g., programming commands and measurement results) and out-of-band messages (e.g., serial poll, device clear, etc.).
More recently, the USB was developed to provide a standard, easy-to-use connection for up to 127 devices, with each device sharing the available twelve megabits per second of bandwidth. However, the USB cable has only two wires for power (+5 volts and ground) and a twisted pair of wires to carry the data. As such, the USB cable does not offer the flexibility of dedicated lines provided by the GPIB. Instead, the USB bandwidth is managed by the controller as frames (i.e., data transferred per specified time). During a one millisecond USB frame, isochronous and interrupt signals have guaranteed bandwidth and bulk and control transfers use the leftover bandwidth, if any.
According to one USB protocol for communicating with a device, a bulk data-out packet is transmitted from the controller requesting data (e.g., a voltmeter reading) from the device. The controller then continues to send bulk data-in packets, requesting the data, to the device. These bulk data-in requests are not acknowledged by the device (i.e., return with no payload) until the requested data is available, at which point the requested data is transmitted to the controller.
The controller, operating according to the above-described USB protocol, incurs overhead by setting up and sending the bulk data-in packets. In addition, when scheduling the bulk data-in transactions, the controller must anticipate that the device will return a full USB data payload, therefore consuming USB bandwidth. Furthermore, the scheduling of data-in packets is not deterministic. That is, the USB places the lowest priority on bulk data transfers. Thus, the bulk data-in packets may be delayed by higher priority USB transactions (e.g., interrupt or control transfers).
The inventors have devised an apparatus and method for communicating between a controller and a message processing device over a USB.
One embodiment of the apparatus comprises an interface for communicating between a message processing device and the controller over the USB. The interface comprises a bulk data-out endpoint for receiving a data-out packet from the controller that requests data from the device. The interface also comprises an interrupt-in endpoint. The interrupt-in endpoint receives interrupt-in packets from the controller. The interrupt-in packets are requests for the status of the data that has been requested from the device. When the requested data becomes available, logic at the interface transmits the status from the interrupt-in endpoint to the controller. In addition, when USB bandwidth so permits, logic at the interface also transmits the data with the status from the interrupt-in endpoint to the controller. Alternatively, where the data is not transmitted with the status, upon receiving the status the controller queries the interface at a bulk data-in endpoint for the requested data. The device responds through logic at the interface by transmitting the data from the bulk data-in endpoint to the controller in response to the query. The interface may also comprise a bidirectional control endpoint for communicating control signals (e.g., device clear) between the device and the controller.
Another embodiment comprises an apparatus for communicating between a GPIB message processing device and the controller by sending GPIB signals over the USB. The apparatus comprises a bulk data-out endpoint and logic for receiving a GPIB in-band message at the bulk data-out endpoint via the USB. The apparatus further comprises an interrupt-in endpoint and logic for receiving a GPIB out-of-band message at the interrupt-in endpoint via the USB. The GPIB out-of-band message requests a status from the device, and indeed, may do so until the status is received. That is, a poll interval, which can be read by the computer during enumeration (i.e., USB configuration) of the device, is used to determine a frequency for transmitting a USB packet to the interrupt-in endpoint. In response, a GPIB status byte including the requested status is sent from the interrupt-in endpoint via the USB to the controller. Once the status is received by the controller, the controller queries the device with a GPIB in-band message sent to the bulk data-in endpoint at the device via the USB. Again, the apparatus may include a bidirectional control endpoint and logic for sending and receiving a GPIB out-of-band message at the bidirectional control endpoint via the USB. Alternatively, the apparatus may further comprise logic for sending a GPIB in-band message from the interrupt-in endpoint when USB bandwidth allocated to the interrupt-in endpoint so permits.
A method for communicating between a controller and a device over the USB may comprise requesting data from the device over the USB via a bulk data-out packet transmitted from the controller to a bulk data-out endpoint of the device. Subsequently, the device is polled for a status of the requested data over an interrupt-in pipe of the USB. Preferably, the device polling is at a regular frequency until the status and the requested data are received at the controller. That is, in response to the polling, the requested data is received at the controller over the interrupt-in pipe in a single transmission via the USB from an interrupt-in endpoint of the device. The method may further comprise transmitting control signals between the controller and the device via a bidirectional control endpoint.
Alternative embodiments of the method for communicating GPIB signals between the controller and the device via the USB may comprise requesting data from the device over the USB with a data-out packet transmitted via the USB from the controller to a bulk data-out endpoint of the device. Subsequently, the device is polled for a status of the requested data over an interrupt-in pipe of the USB. Preferably, polling the device is with an interrupt-in packet transmitted via the USB from the controller to an interrupt-in endpoint of the device. In response to the polling, the status is received at the controller, and the controller queries the device (i.e., with a data-in packet transmitted to a bulk data-in endpoint of the device) for the requested data. In response to the query, the controller receives the requested data.
The invention minimizes the effort to modify existing controller and device software for communicating GPIB signals over the USB. That is, GPIB in-band and GPIB out-of-band messages can be transmitted to the device over the USB to specified endpoints at the device. For example, control messages are sent to a control endpoint at the device, and status requests are sent to an interrupt-in endpoint at the device. In addition, communication according to the teachings of the invention conserves the availability of USB bandwidth by using interrupt transfers as opposed to bulk transfers to obtain the status of the requested data. Bulk transfers of the requested data are only required where there is insufficient bandwidth available on the USB to return the requested data with the status via an interrupt transfer. Furthermore, the invention eliminates the overhead associated with multiple bulk transfers before the requested data is ready to be transmitted to the controller, by instead polling the device with interrupt transfers. In addition, the invention reduces the latency in obtaining responses from the device by using interrupt transfers having guaranteed bandwidth to obtain the status of the requested data from the device.
These and other important advantages of the invention will be further explained in, or will become apparent from, the accompanying description, drawings and claims.